| Arcserve |
5.0 Considerations/Limitations
6.0 Installation
6.1 Prerequisite Tasks
6.2 Installation Instructions
Welcome to the Arcserve UDP Version 5.0 Update 3 Release Notes. This Release Notes contains important information about this update. Updates are cumulative and can be installed on any previous version of Arcserve UDP. Arcserve UDP Version 5.0 Update 3 is not automatically downloaded and installed to your system (through the Updates feature within the product), but instead requires a manual download from the links provided in the Installation Instructions.
The following enhancements or features have been added to Arcserve UDP for this update:
Each Arcserve UDP 7000 series appliance is a self-contained, "set and forget" backup and recovery solution. The Arcserve UDP 7000 series appliance is fully integrated with the industry-leading Arcserve Unified Data Protection software pre-installed in state-of-the-art hardware. Architected with cloud-native capabilities, its unmatched ease of deployment and usability combine with a broad set of features such as global source-based deduplication, multi-site replication, tape support, and automated data recovery capabilities. The Arcserve UDP 7000 series delivers unmatched operational agility and efficiency, and truly simplifies disaster recovery activities.
The dashboard tab lets you view a graphical representation of the Raw Data size, Actual Data Storage, and the Restorable Data size for the last seven days, as well as the Last Backup Status.
This is the old dashboard tab in the previous release. It displays the status of the jobs for a specific period. You can apply filters to categorize the results or you can group the jobs by plan.
This update fixes the following issues, which could have occurred:
Symptom
The server cannot boot up after a BMR from a specific recovery point, and keeps booting into repair mode or keeps rebooting.
Cause:
The Arcserve UDP Agent cannot back up data consistently during an NTFS transaction. If the backup is performed after the NTFS transaction starts and before the NTFS transaction commits the data, the uncommitted data may not be backed up properly. Any following Incremental backups carry this problem forward. A Full backup or a Verify backup can fix this problem for a newly created recovery point.
Solution
Upgrade to Arcserve UDP Version 5.0 Update 3, and perform a Full backup.
Note: Before you upgrade to Arcserve UDP Version 5.0 Update 3, review the following backward compatibility considerations in your environment:
The backup job of a Hyper-V cluster VM becomes a Verify backup and there is a warning in the activity log “The Change Block Tracking feature is inactive on the Hyper-V host”. This problem occurs when one of the Hyper-V hosts in the cluster is evicted from the cluster and then shuts down immediately.
A Hyper-V VM is placed into Saved state for 1 or 2 minutes during the “take snapshot” stage of the backup (after the “take snapshot” stage, the VM will resume automatically). The problem where a VM is placed into Saved status may happen in a Hyper-V 2008 R2 or Hyper-V 2012 environment. For Hyper-V 2012 R2, this problem may happen before Windows Update 2919355 is applied.
For all issues fixed in this release, see the Arcserve UDP Version 5.0 Release Notes.
The following issues could exist in this update:
Symptom
VMware has a bug when quiescing a VM so that its snapshot contains corrupted data. The backup reads data from the snapshot so that the data backed up also becomes corrupted. For more information about this issue, see the following VMware KB article: Application quiescing with Windows 2008 R2 SP1 and Windows 2012 with vSphere Data Protection, VMware Data Recovery, and third-party backup software (2146402).
Note: This problem can occur with all VMware ESXi versions and on a VM with guest OS Windows 2008 R2 SP1 and Windows 2012. The data corruption problem cannot be detected by the software because VMware does not return an error in this case. This may lead to the situation that you are not aware of the problem until you try to restore some data.
Solution
Perform the following methods provided in this update to detect and resolve the problem:
Symptom
When the source machine is a Windows 8.1 or Windows 2012 R2 system and you perform a BMR on a machine with a 4 KB disk, it may fail to boot the machine after BMR with error message: system_thread_excption_not_handled (WppRecorder.sys).
Solution
Boot to the recovery console (you should automatically get there after a few Blue Screen crashes).
c:\windows\system32\compact.exe /U c:\windows\system32\drivers\*.sys
fsutil behavior set DisableCompression 1
Symptom
A migration job does not show in the Nodes list view on the resources tab.
Solution
Access the RPS view or jobs tab to check the job monitor.
Symptom
Cannot browse volumes in the Arcserve UDP Recovery Point View.
Solution
Use a UNC path directly instead of mapping to a network drive.
The Windows version of proxy [<Proxy Name>] is an earlier version than virtual machine [<Virtual Machine Name>]. As a result, the subsequent Exchange catalog job may fail, and you will need to install the related Windows update package to resolve the problem."
Symptom
The Exchange catalog job will use the Exchange binaries from the virtual machine. If the Windows version of the proxy machine is an earlier version than the virtual machine, the Exchange binaries do not work well, and as a result, the catalog job will fail.
Solution
Install the following Windows update package to resolve the problem:
Symptom
Failover happens for the clustered VM before taking a snapshot when backing up a VM. This causes the Hyper-V host recorded in the backup session to be inconsistent with the VM configuration.
Solution
You can manually connect the network adapter to a virtual switch on its Hyper-V host or use the Restore to an alternative location option to recover the VM with which you can set the restore configuration for the VM.
Symptom
Suppose you migrate a Linux Backup Server to the Arcserve UDP Console. If you release the Linux Backup Server and then migrate it again, you will see a new plan is automatically created on the Console.
Example:
You have a Linux Backup Server1 that manages Linux_Node1. You have created a backup job named New Plan. You also have a Arcserve UDP Console that manages Linux_Node2 and Linux Backup Server2 and the plan is also named New Plan.
You migrate Linux Backup Server1 to Console using the d2dreg command. After the migration, the backup job name changes to New Plan_<Linux Backup Server1>. Deploy New Plan_<Linux Backup Server1>.
Now you add Linux_Node1 to New Plan and add Linux Backup Server1 as the server and deploy the plan. New Plan now protects Linux_Node1 and Linux_Node2 and the server is Linux Backup Server1.
Now you release Linux Backup Server1 from Console. Delete New Plan and New Plan_< Linux Backup Server1> from Console. When you migrate Linux Backup Server1 again to Console, two plans get migrated: New Plan and New Plan_<Linux Backup Server1>.
Solution
Delete the new plan. The new plan does not have any nodes, therefore, it does not affect any backup schedule.
Symptom
Although the backup job of one virtual machine has already finished, the virtual machine's status is still “Backup up” in the Hyper-V Manager. Therefore, if another backup job for this VM starts at this time, it will fail with error “The Hyper-V VSS writer has encountered an error when processing this virtual machine”. In addition, you cannot perform some operations, such as power on/off for the VM at that time in Hyper-V manager. And if the VM is Hyper-V cluster, you cannot perform live migration for it.
This problem happens during the following situations:
• There are several backup jobs starting at the same time or at times close to each other (within 1 minute).
• One or more backup jobs finished, but there is still at least one backup job which is still in progress.
Root of the problem:
To avoid bringing unnecessary workload to the Hyper-V host, instead of taking one VSS snapshot for each VM, Arcserve UDP tries to take one VSS snapshot for all VMs if their backup jobs start at the same time or at times close to each other. After the VSS snapshot is taken, all the VMs inside this VSS snapshot instance will be “locked” (in Backing up status). Because Arcserve UDP cannot release the snapshot until all backup jobs are finished, even if the backup job of a VM already completed, that VM is still “locked”. Due to the limitation of VSS snapshot that only one snapshot can be taken for one VM at one time, if another backup job of the same VM starts at this time, it will fail with the error “The Hyper-V VSS writer has encountered an error when processing this virtual machine”. In addition, some operations (such as power on/off) are disabled in Hyper-V Manager and, if the VM is in a Hyper-V cluster, live migration is also not allowed. This does not happen in Hyper-V 2008R2 because Hyper-V 2008R2 has different behavior on the VSS snapshot mechanism.
Solution
While the VM is “locked”, you can still use the guest OS as normal. Therefore, this has no impact on the usage/availability of the guest OS. However, if you have concerns and want to avoid this situation, you can do either of the following:
Symptom
The UI may respond slowly when accessing Arcserve UDP Agent (Windows) from Internet Explorer 10 or 11, if you are using any of the specific versions of Internet Explorer 10.0.9200.17XXX and Internet Explorer 11.0.9600.17XXX.
If this issue occurs, all other subsequent requests will wait for response for 5 minutes.
This issue only happens when using any of the versions of Internet Explorer 10 and 11 mentioned. All other browsers do not have this issue.
Solution
Perform one of the following temporary solutions:
Perform the following permanent solution:
Solution
Create a new virtual disk with any value other than 1 MB.
Solution
Contact your domain administrator for help to authorize the DHCP server before using the Arcserve UDP Linux Backup server.
Symptom
There is a dead lock in the file system while taking a snapshot when the granular restore catalog job is running.
The following conditions may trigger the problem:
Solution
Configure the following registry key to move the cache file to another location which is not protected by the Arcserve UDP Engine:
HKEY_LOCAL_MACHINE\SOFTWARE\CA\ARCserve Unified Data Protection\Engine\AFStorHBAMgmt\CacheFilePath
If the "AFStorHBAMgmt" key does not exists, you have to create a new one.
Example: If your backup destination is local drive E:, the backup snapshot will be created on Drive E: into the backup destination path.
Example: E:\temp then E:\temp is used as cache store path.
Note: This issue happens when the I/O load is high, and the following conditions exist:
Taking a snapshot will notify the file system driver to flush incomplete data to the volume, and will hold off all new write operations to all volumes for a short time. This will create a dead lock where the mounted volume is flushing data to the file, and at the same time the writer operation is holding off on the volume where Arcserve UDP is installed.
Solution
Reopen the Restore wizard and try selecting the database again.
Symptom
In the Arcserve UDP console, you have successfully updated an agentless backup proxy node with new credentials. However, the new credentials do not take effect and old credentials are used by the Arcserve UDP engine to start the backup process. This happens only when no agent-based backup plan is deployed to the proxy node.
Example:
Solution
As a workaround, create an agent-based backup plan and add your proxy as a protected node (make sure to remove all schedules from the plan), and then update the proxy node again.
Symptom
After upgrading to Google Chrome v41, you are no longer able to browse the Arcserve UDP/Arcserve D2D Agent for Linux web pages if HTTPS is used as the communication protocol. (HTTPS is the default protocol for Arcserve UDP/Arcserve D2D Agent for Linux). The following message will be displayed:
This webpage is not available
Error code : ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Note: This problem affects all releases of Arcserve D2D for Linux and Arcserve UDP.
Solution
On the Arcserve UDP/Arcserve D2D Linux backup server machine, open the command line as an administrator and run the following commands:
#source /opt/CA/d2dserver/bin/setenv #d2dserver stop #mv /opt/CA/d2dserver/TOMCAT/conf/server.keystore /opt/CA/d2dserver/TOMCAT/conf/server.keystore.old #keytool -genkey -alias tomcat -keyalg RSA -keypass LinuxD2D -storepass LinuxD2D -keystore /opt/CA/d2dserver/TOMCAT/conf/server.keystore -validity 3600 -dname "CN=hostname_of_backup_server" #d2dserver start
Notes:
For more information about this problem, see https://arcserve.zendesk.com/hc/en-us/articles/204506105
Symptom
After upgrading to Google Chrome v41, you are no longer able to browse the Arcserve UDP/Arcserve D2D Agent for Windows web pages if HTTPS is used as the communication protocol. (HTTPS is the default protocol for Arcserve UDP/Arcserve D2D Agent for Windows). The following message will be displayed:
This webpage is not available
Error code : ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Note: This problem affects all releases of Arcserve D2D for Windows and Arcserve UDP Console.
Solution
On the Arcserve UDP/Arcserve D2D Windows machine, open the command line as an administrator, and run the following commands:
cd C:\Program Files\CA\arcserve Unified Data Protection\Engine\TOMCAT\conf move server.keystore server.keystore.bak ..\jre\bin\keytool -genkey -alias tomcat-sv -keyalg RSA -keypass ARCServeD2D -storepass ARCServeD2D -keystore server.keystore -validity 18250 -dname "CN=server_host_name" -ext san=dns:localhost,dns:server1,dns:server.domain.com cd C:\Program Files\CA\arcserve Unified Data Protection\Engine\bin Changetohttps.bat
Notes:
For more information about this problem, see https://arcserve.zendesk.com/hc/en-us/articles/204542275
Symptom
The behavior of the operating system creates the offline state by default.
The SAN policy was introduced in Windows Server 2008 to protect shared disks that are accessed by multiple servers. The default SAN policy from the source VM is “Offline Shared” for all SAN disks except the boot disk. Setting the policy to Offline enables the SAN disks to be offline during startup. After recovery, a new disk for the VM is created. The disk file from the VM appears to be a SAN disk where the operating system identifies it as being offline. When the offline disk is set to be back online, the disk remains online even after rebooting the system.
Solution
As a workaround, specify the DISKPART.exe command: SAN POLICY=OnlineAll setting for the source VM before backup. Because the disks can be shared among other servers, data corruption can occur. You must use the correct SAN policy to protect the data.
DISKPART.EXE command line
Query SAN policy:
DISKPART > san
SAN Policy: Offline Shared
Change SAN policy:
DISKPART > san policy=OnlineAll
DISKPART successfully changes the SAN policy for the current operating system.
For all known issues in this release, see the Arcserve UDP Version 5.0 Release Notes.
The following considerations could exist in this update:
The following limitations could exist in this update:
Note: This limitation exists only for VMware VMs, which has the option to set the OS type. For Hyper-V, this problem does not exist.
Symptom
When you log in to the Arcserve UDP appliance with a domain account, the appliance wizard is not immediately launched. A User Account Control dialog displays asking you to confirm allowing the program to make changes to the computer.
Solution
From the User Account Control dialog, click Yes and the wizard will be launched.
For all considerations or limitations in this release, see the Arcserve UDP Version 5.0 Release Notes.
The following sections provide information about installation prerequisites and installation instructions.
Consider the following prerequisite tasks before installing this update:
When installing the Arcserve UDP update or the Arcserve UDP Agent (Windows) update, it is important to maintain optimal performance between the Console, the Recovery Point Server (RPS), and the Agents. As a result, when the update is installed in an environment that contains both a Console and an Agent, you must always install the update on the Console first, and then on the RPS, and finally on the Agent. (For the Agent that is installed on the Console or the RPS, the update will be automatically installed on that Agent at the same time).
Note: If you have an environment with both Arcserve UDP and Arcserve Backup installed, and you want to install Arcserve UDP Version 5.0 Update 3, you need to also install the corresponding Arcserve Backup patch RO75131 at the same time.
Installing the Update Manually
Note: Arcserve UDP Version 5.0 Update 3 is not automatically downloaded and installed to your system (through the Updates feature within the product), but instead requires a manual download from the links provided in the Installation Instructions.
For an upgrade installation package for Windows servers and workstations that have a previous version of Arcserve UDP already installed, download and install the update manually using the following links to the installation files:
For a fresh installation package for Windows servers and workstations that do not have Arcserve UDP installed yet, perform the following tasks:
Download and install Arcserve UDP Version 5.0 Update 3:
For a Linux installation, download and install the update manually using the following links to the installation files:
The Arcserve Support team offers a rich set of resources for resolving your technical issues and provides easy access to important product information.
With Arcserve Support:
Copyright © 2015 Arcserve. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.